System, apparatuses, methods, and computer-readable media for identification of user and/or source of communication in a network

ABSTRACT

A method, system and program for preventing intrusion in a communications network. A source node initiates a request for network services, such as session establishment, database access, or application access. Known network resources and authorized user information is stored in a database at a network portal along with access policy rules that are device and user dependent. Identification of the source node is required before the source node can construct a transformed packet header that is included with a synchronization packet before transmission to a destination node. An appliance or firewall in the communications network receives and authenticates the synchronization packet before releasing the packet to its intended destination. The authentication process includes verification of the access policy associated with the source node. Once received at the destination node, the transformed packet header is reformed by extracting a key index value. The extracted key index is subsequently used to transform the packet header in the response transmitted to the source node.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application is a continuation under 35 U.S.C. §120 and 37C.F.R §1.53(b) of U.S. application Ser. No. 10/065,775 filed Nov. 18,2002 naming as inventor A. David Shay, which is hereby incorporatedherein in its entirety by reference.

BACKGROUND OF THE INVENTION

[0002] This invention relates generally to network security. Morespecifically, the invention relates to a system and method for providingtrusted communications and preventing intrusions in computercommunications networks from occurring.

[0003] In the current state of the art, the common approach tocommunications network security is an attempt to identify occurrences ofattacker activity after the attacker is present. This requiresinfrastructure inspections of every packet flow and a state-fullinspection at the packet level. After performing all of this work mostof these approaches only provide alert messaging of active breaches,thousands of them. Other approaches in security utilize personalencrypted keys and key authentication. These approaches while providingan attempt at session level control carry additional concerns andlimitations associated with Quality of Service (QOS) performance impactsalong with the need to add additional information to each packet; thus,by looking at the packet, intruders have a clear picture of how andwhere to modify new packets. In the present context QOS refers to theoverall throughput and performance of a network infrastructure. Mostcorporate security approaches also include anti-viral, signatureverification and Network Address Translation (NAT) implementations. NATenables a local area network to use one set of Internet Protocol (IP)addresses for internal traffic and a second set of addresses forexternal traffic. Recent attempts have been made to apply flow-basedlogic to identify hacker activity. However, like their predecessors,these new approaches still rely on “after intrusion” recognition. Whileimprovements have been made to keep up with today's high-speed linerates, intrusion detection is still just that, detection not prevention.

[0004] Network security is of paramount importance to networkadministrators today. Cyber attacks are becoming more frequent and morepublicized. Concerted cyber attacks by terrorist organizations can wreakhavoc on the infrastructure that modern societies have come to dependupon. The common methods of attack include network packet sniffing,Internet Protocol (IP) spoofing, password attacks, denial of serviceattacks and application layer attacks. All of these methods requiregaining access to the network and no comprehensive solution exists inthe prior art to prevent all forms of network intrusion.

[0005] A current effort to provide secure private communications overthe Internet is Internet Protocol Security (IPSec). This framework usesencryption technology to provide confidentiality, integrity andauthenticity between peer devices in a private communications network.The IPSec protocol is a set of security extensions to the TCP/IPprotocol that uses cryptographic techniques to protect the data in amessage packet. The main transformation types are authentication header(AH) transformation and encapsulating security payload (ESP)transformation. AH transformation provides for authentication of thesender of data. ESP transformation provides for authentication of thesender and encryption of data. Both types of transformations can be madein either transport or tunnel mode. Transformation in transport modemeans that the original packet IP header will be the IP header for thetransformed packet. Transformation in tunnel mode means that the packetis appended after a new IP header. Both AH and ESP transformations addan extra header to the message packet, i.e., an AH header or an ESPheader. Separate key protocols can be selected including the Internetkey Exchange (IKE). Session keys have to be exchanged betweencommunicating peers in order to provide secure communications. AlthoughIPSec does address certain aspects of network security, it is not apanacea for all types of attacks. The use of an AH transformation doesnot protect the confidentiality of data; the use of an ESPtransformation protects the confidentiality of data, but also requireskey exchange, the use of additional headers increasing packet overhead,and the encryption of the actual data payload.

[0006] There is a critical need for an improved method and system forproviding network security that actually prevents intrusions into thenetwork and provides trusted communications between devices in thenetwork.

SUMMARY OF THE INVENTION

[0007] The present invention provides an access control and user sessionlayer security framework. It prevents unwanted connections to new andexisting computing resources. It prevents unknown devices and/or usersfrom establishing communication connections to the infrastructure. Itprevents unknown devices and/or users from establishing sessions toshared application resources. It prevents known users from gainingaccess to application resources that are not required in the executionof their area of responsibility.

[0008] Unlike traditional intrusion detection systems, the presentinvention can be used to prevent intrusions rather than simply alertinga network administrator that an intrusion is occurring. The techniqueused by this invention is the first security approach that linksbusiness process to enabled technology utilization; thereby preventinganomalies in access and session establishment. It utilizesauthentication through real-time protocol manipulation.

[0009] The invention requires granted authentication at the hardware anduser session levels; thus linking hardware access to user requestedservices. By securing granted permissions at these levels, strange orunknown hardware devices are prevented from communicating with thenetwork infrastructure; thus preventing threats associated with“walk-in” intrusions. Additionally, application resources are secured bycontrolling where user sessions are allowed; thus preventing “insiders”from gaining access to non-permitted resources and data.

[0010] The invention prevents the initiation of communicationestablishment through extended manipulation of the communicationprotocol. This approach places the decision point to the forefront ofconnection establishment rather than current methods of detectingunwanted “active” utilization or flow. It also eliminates therequirement for “state-full” inspection of every packet associated withend-to-end flows of utilization; thus lowering the performance burdennormally associated with intrusion detection.

[0011] Two major components of the invention are a “key master” softwarecomponent that is added to individual user workstations and networkresources, and a “gate keeper” component that can be added to existingfirewall devices or operate as a stand alone appliance within a trustedvirtual network. The key master software constructs a “transformed”packet header for a synchronization packet before transmitting thepacket to a destination node. The gate keeper component is an in-lineappliance or software module that intercepts all packet flows associatedwith a protected trusted virtual network. It processes the initialsynchronization packet received from a transmitting node and releasesevery other packet without further delay. The synchronization packetsare inspected to ensure that known hardware and known users arerequesting services for network resources that they can access. Thisinspection is performed by examination of the transformed packet headerin the received synchronization packet. Information contained in thesynchronization packet is compared to access policy profiles stored in arelational database management system at a network portal. Decisions topermit or reject the request for access to network services are madebased on these comparisons. At the receiving end of a connectionrequest, key master software in the receiving node initially identifiespacket type and evaluates a packet header field to determine whether tocontinue processing the packet. Authorization and verification areperformed by extracting and transforming data in packet header fieldsand passing the data to upper protocol layer stack processes. The keymaster software in the destination node toggles into a conversation modethroughout the rest of the connection until both the originating anddestination nodes are informed of the connection's termination.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The invention is better understood by reading the followingdetailed description of an exemplary embodiment in conjunction with theaccompanying drawings, wherein:

[0013]FIG. 1 illustrates a system architecture for implementation of thepresent invention in accordance with an exemplary embodiment.

[0014]FIG. 2A illustrates the fields and overall format of a TCP packet.

[0015]FIG. 2B illustrates the fields and format of a UDP packet.

[0016]FIG. 3 illustrates a high level view of the major functions in theprocess flow for the key master and gate keeper intercept software inaccordance with an exemplary embodiment of the present invention.

[0017]FIG. 4 illustrates the processing logic associated with requestingnetwork connection services in accordance with an exemplary embodimentof the present invention.

[0018]FIG. 5 illustrates the processing logic associated with the gatekeeper authentication process to prevent intrusion in a communicationsnetwork in accordance with an exemplary embodiment of the presentinvention.

[0019]FIG. 6 illustrates the processing logic associated with the“perform exception” process in accordance with an exemplary embodimentof the present invention.

[0020]FIG. 7 illustrates the processing logic associated with call setupand response at a destination in accordance with an exemplary embodimentof the present invention.

[0021]FIG. 8 illustrates the processing logic associated with packetflow after a connection is established between two nodes in accordancewith an exemplary embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0022] The following detailed description of the present invention isprovided as an enabling teaching of the invention in its best, currentlyknown embodiment. Those skilled in the relevant art will recognize thatmany changes can be made to the embodiment described, while stillobtaining the beneficial results of the present invention. It will alsobe apparent that some of the desired benefits of the present inventioncan be obtained by selecting some of the features of the presentinvention without using other features. Accordingly, those who work inthe art will recognize that many modifications and adaptations to thepresent invention are possible and may even be desirable in certaincircumstances, and are a part of the present invention. Thus, thefollowing description is provided as illustrative of the principles ofthe present invention and not in limitation thereof, since the scope ofthe present invention is defined by the claims.

[0023] The objective of the invention is to prevent intrusion before itoccurs by identifying intruders when they try to establish a connection.This new approach not only delivers a pre-emptive methodology addressingoutside intruders but addresses internal intruders as well. Outsideintruders are defined as devices originating from the “outside” oroff-net who are attempting to connect to resources located within theenterprise infrastructure. Internal intruders are devices connectedwithin the infrastructure that are attempting to connect to unauthorizedinternal resources.

[0024] Unlike other solutions available today, the invention correlateseach request for service with the individual making the request andapplies availability rules to the users' identification without taggingor modifying packets. The invention utilizes the normal features ofprotocol operation and exploits how the protocol works to provideauthenticated user level security. This approach delivers a securemethod of communications without demanding abnormal construction ofpacket level data.

[0025] The prevention of unwanted communication is best served by simplynot allowing the communication to begin. As an example, when a localtelephone company wants to prevent unwanted telephone usage, they simplyremove the dial tone. Without receiving a dial tone, a communicationcircuit cannot be opened. Much like the telephone, computers rely on theclosure of a virtual circuit to a destination address or device. Byapplying intelligent decision making capability at the point of arequest, unwanted or unallowable connection closure can be terminatedbefore it begins.

[0026] Resource and delay requirements for this approach will be lowerthan the traditional approaches as the requirement for continuousstate-full inspection of all flow related packets is eliminated. Byapplying intelligent decision capability at the beginning of a requestfor connection, only the first few packets must be inspected. Thehand-shaking functions of all connection-oriented protocols duringinitial call setup provide enough information about the request forservice to make the decision whether to acknowledge and allow theconnection to be made or to terminate and drop the request. In addition,after a connection is established information held within the first fewpackets can also be inspected to determine the nature of an acknowledgedconnection request and to recognize the nature of the user's intent. Asan example, denial of service attacks can be identified by evaluatingthe interaction of the first five packets of the bi-directional flowbetween two nodes. Once the system of the present invention hasrecognized that initial interaction as damaging, it can automaticallyterminate the connection.

[0027] Signature or anti-virus enabled methods of countering virus-basedtransmissions can be fully supported by including anti-virus enabledsoftware within the system of the invention. This additional featurewould be available through direct partnership with anti-virus softwarevendors such as Network Associates (McAfee security products) or NortonUtilities.

[0028] The following connection scenarios are addressed by the presentinvention:

[0029] 1. Intercept software-enabled devices connecting to otherintercept software-enabled devices.

[0030] 2. Intercept software-enabled devices connecting to non-interceptsoftware-enabled devices.

[0031] 3. Non-intercept software-enabled devices connecting to interceptsoftware-enabled devices.

[0032] 4. Non-intercept software enabled devices connecting to othernon-intercept enabled devices.

[0033] Scenario 1 can be described as an internal device connecting to acorporate application host. The origination node requests a connectionwith an application host that is within the trusted corporateenterprise. The request for connection is routed through the enterpriseand is evaluated by the corporate firewall already protecting the datacenter, if a firewall is present. An intercept software program looks atthe connection request and ensures that the device making the request isa known node and the authenticated user has permission to utilize therequested application. Once it has been cleared, the request continueson its way to the host destination. The host destination then respondsback to the origination node. Within this response are key indicatorsthat inform the node's intercept software that it has indeed connectedto an intercept software-enabled or approved device; thus allowing thecontinuation of the conversation.

[0034] Scenario 2 can be described as an intercept software-enableddevice connecting to a non-intercept software-enabled host. Thisscenario is applied equally to both internally located hosts and remotehosts. In either case, a “gate keeper” software program evaluatescompliance. The originating node request is evaluated by the gate keepersoftware program implemented as an appliance or running within thefirewall, thus ensuring permissions to connect to the selected host aregiven. The response does not contain the key indicators provided by anintercept software-enabled device. The intercept software running in theworkstation recognizes that it has connected to non-interceptsoftware-enabled device and still continues the conversation. Becauseeach original request for connection is first evaluated by the gatekeeper software implemented as an appliance or running within protectedfirewalls, only permitted requests can complete their connections.

[0035] Scenario 3 describes a non-intercept software-enabled deviceattempting to connect to an intercept software-enabled device. Thisscenario also addresses both internal and external devices. Internaldevices are considered first. As with all other internal originatingrequests, the gate keeper software implemented as an appliance orrunning within the firewall evaluates the request from the internaldevice. It will recognize that the requesting device is not a knownintercept software-enabled device; by applying an exception policy tothe request, gate keeper software will determine if the request isallowed. If allowed, gate keeper software will inform the receivingdevice that it has been cleared and is allowed to respond. If therequest fails the exception policy, gate keeper will drop the requestthus terminating the request. This approach prevents non-allowedconnections from reaching the protected host. If the requesting deviceis entering from outside the network (off net), the gate keeper softwarealso processes the exception policy in the same manner. However, thisscenario also can include an internal device that has been inserted intothe enterprise inappropriately, bypassing the gate keeper software orfirewall. In this case, the originating device will reach thedestination device (server) with a request. However, the interceptsoftware-enabled server either terminates the request or responds backto the originating device with an inappropriate response. The connectionwill be terminated by the IP protocol in its normal handling of brokenconnections.

[0036] Scenario 4 describes non-intercept software-enabled devicesconnecting with other non-intercept software-enabled devices. Byrequiring all protected internal enterprise devices to be interceptsoftware-enabled, no unknown devices will pass the intercept softwareinspection within the gate keeper protecting a trusted virtual network.Corporations that have the requirement for “outside” or globalavailability such as the world wide web (HTTP) and Simple Mail TransferProtocol (SMTP) servers to be used within their buildings can provide adedicated domain or virtual local area network (VLAN) that only hasoutside communication abilities.

System Architecture

[0037] The system architecture of the intercept solution of the presentinvention includes the following components: portal, key mastersoftware, gate keeper software and an intercept management console. FIG.1 illustrates the system architecture of the present inventionpictorially. The figure depicts users 10, 12, 14, 16, 18 connected viaswitch 20 and router 30 to the enterprise network 40. The enterprisenetwork 40 can be a wide area network using the Transmission ControlProtocol/Internet Protocol (TCP/IP) for network communications betweendevices and users. Inside the enterprise network 40 are router 60,firewall server or gate keeper appliance 70, switch 80, servers 90, 92and mainframe 94. The intercept portal 50 and intercept managementconsole 54 are also shown and are further described below. The masterrelational database management system (RDBMS) and policy managersoftware are installed on intercept portal 50. Key master software isinstalled on protected server 90 and mainframe 94, as well as on enduser workstations 10, 12, 14, 16 and 18. The gate keeper software can beimplemented as an appliance protecting a selected trusted virtualnetwork (TVN) within the enterprise network.

[0038] The intercept portal 50 is a central point of initial keygeneration and registration. Users 10, 12, 14, 16 and 18 authenticate tothe portal 50 and receive a unique software package (i.e., key mastersoftware) for their respective node. During the turn-up process users10, 12, 14, 16 and 18 authenticate with the portal 50 using the singlelogin used for network access as configured by the networkadministrator. The portal 50 verifies this authentication with theprimary domain controller (PDC) and either continues with the “keymaster” build or terminates the attempt. The PDC is a server in aWindows NT network that maintains a read-write directory of useraccounts and security information. The PDC authenticates usernames andpasswords when members log into the network. Once the key master hasbeen built, the portal 50 transfers and informs the management console54 of the addition. The intercept administrator will then use theobjective interface to drag and drop additional permission sets to theuser's profile. Once the users' profiles are updated, the users 10, 12,14, 16 and 18 are ready to access all approved resources.

[0039] Key master and gate keeper are software modules that could besimply added to existing firewalls 70 and end nodes, such as 10, 12, 14,16 and 18. Within the firewall or appliance 70, gate keeper softwareprovides individual session layer protection from unwanted access bycontrolling the initial request for connection. Node key master softwareprovides a unique identifier for each user 10, 12, 14, 16, 18 anddevice; thus allowing gate keeper full recognition of who is requestingservice and what service is being requested.

[0040] The intercept software (key master and gate keeper) prevents theability to misuse resources by preventing unwanted users and non-allowedrequests to make connections. Rather than terminating an existing flow,the intercept software prevents the connection all together. Duringtimes where unwanted connections are continuously being requested,intercept software will re-direct the requests to an aggregation areawhere security personnel can “back-through” the connection and locatethe intruder. The intruder will not know that he is being tracked; thusavoidance measures will not be taken by the intruder.

Transformation/Reformation Processes

[0041] Two of the critical elements of the intercept framework are theprocesses of transformation and reformation. Transformation is theprocess of uniquely changing the values and alignment of hidden useridentifiers (UID) and system identifiers (SID) that describe who theuser is, what the user is attempting to use, the system being used andthe active session of the on-going connection. Reformation is theprocess of reversing the transformed identifiers yielding the true valueof each identifier. These “real” identifiers are then used to enforceaccess and usability policies. The objective of transformation is toprovide a mechanism that prevents the transmission of usable identifiersacross an open network. By transforming identifiers used by theintercept software and the TCP/IP stack before they are transmitted,potential intruders can only see what is on the wire, not what isactually being processed.

[0042] Transformation is accomplished by applying keys in a specific waythat changes the original values of each identifier. These changesaffect the original value and the ordering of the bits. Transformationkeys are randomly selected from two key tables each containing 256unique keys. The tables are referred to as the general key index (GKI)and the session key index (SKI), respectively. Each key has anassociated key index number that points to its value. Key indexes arerandomly selected by the key master software each time there is a newconnection request.

[0043] The GKI table holds 256 keys that are used to change the value ofan identifier. As an example, consider a UID that has a “real” value of1234567890, a GKI key index number is randomly selected (157) and anassociated key that is extracted from the GKI table. Once transformedusing this key, the UID identifier's value is now changed (i.e.,transformed) to 5672348901. The GKI index number is then appended to thetransformed UID yielding 5672348901157.

[0044] A key index is then selected from the SKI table (e.g., 78). TheSKI table holds 256 keys that are used to re-order the bits of eachidentifier throughout the life of the connection. Taking the aboveresulting number 5672348901157, the SKI key is applied transforming thenumber to 2319057547186. This resulting number is then used as thetransmitted initial sequence number (ISN) within the TCP/IPsynchronization (SYN) packet header.

[0045] As mentioned above, the intercept key master software alsoidentifies the system being used (SID). Continuing with the aboveexample, a computed SID is 6789012345. The SKI index number used tore-order the transformed UID number is appended yielding 678901234578.This number is then re-ordered using a third key resulting in the finalacknowledgement (ACK) number 307281584697 that is included in the SYNpacket header.

[0046] When the gate keeper appliance (software) intercepts the SYNpacket and parses its header information, the SYN and ACK numbers areextracted. Using the third key, the software reforms the ACK numberyielding the SID and SKI. The SKI is extracted and used to reform theISN yielding a transformed UID and GKI. The GKI is used to reform theUID yielding the real UID.

[0047] Once the SYN packet has been received at its destination, theTCP/IP stack program begins parsing and processing the SYN packetnormally. However, before it begins the process of verifying TCP headerdata, it uses the third key to reform the ACK number yielding the SIDand SKI. It stores the SKI and uses it to transform/reform all incomingand outgoing packets for the duration of the connection.

Key Tables

[0048] As described above, there are two distinct key tables or arrays(GKI, SKI). Each table contains 256 128-bit keys and indexes pointers)to each. These tables are managed and updated in one of two ways.Initially, both tables are pre-populated with all 256 keys prior toimplementation in a communications network. Subsequently, the keys heldin these tables can be re-populated automatically with new key valuesthat are generated by a key generator. This automatic table feature canbe scheduled based on the network owner's requirement and performed bythe network's intercept software administrator.

[0049] As part of the intercept software interface and managementconsole program, a selectable feature (“Key Table Maintenance”) optioncan be used by the administrator. This option schedules the tables forupdating and performs replication services needed to update gate keeperappliances and key master-enabled users.

[0050] The intercept system exploits the normal operational aspects ofcommunication protocols such as Transmission Control Protocol (TCP),User Datagram Protocol (UDP) and others. Brief descriptions ofconnection oriented and connectionless transport protocols are describedin the following sections.

Connection Oriented Protocols

[0051] Connection oriented protocols such as TCP/IP, Internetwork PacketExchange/Sequenced Packet Exchange (IPX/SPX) and others rely onhandshaking events to establish a connection. Connection establishmentbetween TCP hosts is performed by using a three-way handshake mechanism.A three-way handshake synchronizes both ends of a connection by allowingboth sides to agree upon initial sequence numbers. This mechanismguarantees that both sides are ready to transmit data and know that theother side is ready to transmit as well. This is necessary so thatpackets are not transmitted or re-transmitted during sessionestablishment or after session termination. Each host randomly chooses asequence number used to track bytes within a stream it is sending andreceiving. The first host (host A) initiates a connection by sending apacket with the initial sequence number (ISN) and SYN bit set toindicate a connection request. The second host (host B) receives theSYN, records the sequence number, and replies by acknowledging the SYN(within ACK=ISN_(A)+1). The second host includes its own initialsequence number (ISNB). An ACK=20 means that the host has received bytes0-19 and expects byte 20 next. This technique is called forwardacknowledgement. The first host then acknowledges all bytes the secondhost has sent with a forwarded acknowledgement indicating that the nextbyte the first host expects to receive is ACK=ISN_(B)+1. Data transfercan then begin. By investigating information about the requesting user,the intercept system can ensure that each requestor is calling for anallowable connection before the connection is completed. Additionally,the intercept system can identify the intent of the requestor and ensurethat he is asking for a “normal” or “acceptable” service.

[0052] The fields and overall format of a TCP packet are shown in FIG.2A. The source port and destination port fields identify points at whichupper layer source and destination processes receive TCP services. Thesequence number field usually specifies the number assigned to the firstbyte of data in the current message. In the connection-establishmentphase, this field is also used to identify an initial sequence number tobe used in an upcoming transmission. The acknowledgement number fieldcontains the sequence number of the next byte of data that the sender ofthe packet expects to receive. The data offset field indicates thenumber of 32-bit words in the TCP header. The flags field carries avariety of control information, including the SYN and ACK bits used forconnection establishment, and the FIN bit used for connectiontermination. The window field specifies the size of the sender's receivewindow. This represents the buffer space available for incoming data.The checksum field indicates whether the header was damaged in transit.

Connectionless Protocols

[0053] UDP, multicast and other protocols do not utilize a handshakemethod of establishing a connection. UDP is a connectionlesstransport-layer protocol that belongs to the Internet Protocol family.UDP is basically an interface between IP and upper layer processes. UDPprotocol ports distinguish multiple applications running on a singledevice from one another. UDP is useful in situations where thereliability mechanisms of TCP are not necessary, such as in cases were ahigher-layer protocol might provide error and flow control. UDP is thetransport protocol for several well-known application layer protocols,including Network File System (NFS), Simple Network Management Protocol(SNMP), and Domain Name System (DNS). The UDP packet format containsfour fields as shown in FIG. 2B. These include source and destinationports, length, and checksum fields. Broadcast type flows operate in auni-directional fashion; thus the intercept system locates uniqueidentifiers differently than those using a connection-oriented protocolbut will still prevent unwanted flows by pooling the broadcast streamand verifying the initial packet of the stream.

[0054] There are two levels of device authentication and identificationproviding hardware and user session security. First, information aboutthe specific device is maintained in the key master software. Thisinformation maintains a description of the hardware and is verified eachtime the device is used. By placing this information within the keymaster software, the software itself cannot be copied and placed onother devices. Without successful authentication, no networkconnectivity will be permitted. Secondly, unique identifiers are createdeach time the device is used by a user. This information is uniquelytransformed and becomes part of the normal packet structure. All uniqueidentifiers and other unique data points are computed together formingthe initial sequence number (ISN) of the request. Communicating hostsexchange ISNs during connection initialization. Each host sets twocounters: sequence and acknowledgement. Held within the ISN are uniquekeys that identify the user and are used to grant authorization. Byutilizing normal protocol operands to carry authenticated identifiers,no modification to the packet structure is required; thus, intruderswill notice no differences between a non-intercept software-enabledpacket and an intercept software-enabled packet. Only by having acomplete knowledge of how the intercept software operates, theidentification of all data points used in the ISN computation and exactformulas used could a probable breach be successful.

[0055] This initial packet along with the unique identifiers are routedto its destination as usual; however on its way to the destination thepacket is picked up by the gate keeper enabled appliance or firewall.The gate keeper software intercepts synchronize (SYN) packetsspecifically and performs reverse algorithms to the ISN, correlatesencrypted identifiers to fully qualified user name (FQUN). Applicationand destination identifiers are also identified. It then appliesavailability rules to them and either forwards the SYN to itsdestination or rejects and drops the request. The SYN flag is only setwhen establishing a TCP connection.

[0056] The two major components of the intercept system software are theintercept software-enabled firewall or appliance (gate keeper) and theintercept software-enabled node (key master).

[0057] The key master module is a software component that can be addedto user workstations 10, 12, 14, 16, 18 and network resources such asserver 90, mainframe 94 with reference to FIG. 1. The gate keeper moduleis a software component that can be added to existing firewall devicesor operate as a stand-alone appliance 70 as depicted in FIG. 1. As asoftware solution, investments and positioning of existing firewalls canbe leveraged.

[0058]FIG. 3 illustrates a high level view of the major functions of thekey master and gate keeper intercept software. Process blocks 200 and210 indicate functions performed by the key master software at theoriginating node of a network connection. Process blocks 220, 230 and240 indicate functions performed by the gate keeper software onintercepted packets intended for a network destination. Process blocks250, 260 and 270 represent functions of the key master softwareperformed at the receiving end (destination node) of a networkconnection. As indicated in process block 200, the originating station(source node) requests network services. Key master software is loadedand running in all enabled nodes, work stations, servers andintermediate devices. The key master software is responsible for thefirst level of authorization and construction of intercept-enabledpackets. Leveraging the mechanics of the protocol, the key mastersoftware provides a method of identification and verification of boththe hardware and the user. This is indicated in process block 210, whichrepresents the functions of authenticating the system identification(SID), constructing and sending a SYN packet, using a session GKI/SKI.

[0059] The gate keeper in one embodiment is an in-line appliance thatintercepts all packet flows associated with a protected trusted virtualnetwork (TVN). Each packet that is routed in or out of a TVN isinspected in real time. Only the initial SYN packet is processed; allothers are released without further delay. In process block 230, theGKI/SKI is extracted; the ACK and ISN are authenticated; and policyauthorization is checked. SYN packets are investigated to ensure thatknown hardware and known users are requesting services from systems andapplications that they are allowed to use. Using information held in theintercept SYN packet, profiles are compared to the requests. By lookingup these individual profiles, decisions can be made to allow or disallowthe connection request. The packet is released or dropped as indicatedin process block 240.

[0060] At the receiving end of a connection, the receiving node acceptsthe SYN packet to begin the intercept-receive process. This is indicatedin process block 250 with the SYN reaching its destination node. Afteridentification of a packet type (SYN), the ACK field is evaluated and adecision is made to further process the packet. As indicated in processblock 260, the SKI is extracted and used to construct the SYN/ACK.Authorization and verification is performed by extracting andtransforming the ISN and ACK data and passing it to upper layer stackprocesses. The destination node sends a SYN/ACK to the originating nodein process block 270. The key master software toggles into conversationmode throughout the rest of the connection until the FIN/ACK processinforms both the originating node and the destination node of theconversation termination.

[0061] Once the SYN is received by an intercept system protected host,the host responds back in its usual manner. However, the protocoloperands are once again modified. This modification is directed to howthe destination device acknowledges the ISN. Rather than the standardISN+1, the intercept system utilizes an intercept-enabled transformationalgorithm and modifies the sequencing of the flow. If the connectionrequest has originated from a non-intercept system enabled device, thenormal rules of protocol handshaking will terminate the connection thuspreventing the intrusion.

[0062] The gate keeper software includes the following components:

[0063] Packet grabber

[0064] Protocol factory

[0065] Packet parser

[0066] Transformer

[0067] Event broker

[0068] Re-director

[0069] Date store

[0070] Message broker

[0071] The packet grabber is responsible for selecting only the SYNpackets of any given connection request. The packet grabber identifiesSYN packets and send them to the protocol factory for furtherprocessing. Only SYN packets are grabbed.

[0072] The protocol factory is responsible for identifying the protocoland calling the proper parser for packet parsing functions.

[0073] The packet parser selects specific header and frame informationabout the SYN packet. It then performs look up functions to verifypermissions and key identification by calling the transformer. Thepacket parser makes the decision to allow the connection, terminate theconnection request or re-direct the request to the intercept systemconsole. It uses the data store as a decision support tool.

[0074] The transformer reverse computes the transformed identifierswhich contains unique key data. This key data identifies the user makingthe request. Rules are applied to this data so the packet parser canmake a go/no-go decision.

[0075] The event broker executes the actions as directed by the packetparser, either allowing the connection, dropping the connection requestor requesting re-direction. The event broker also logs requests andtheir actions.

[0076] The re-director takes data from the event broker and directs itto multiple places as defined. The data store is used to maintain keyidentifiers and permissions. It is automatically updated through themessage broker.

[0077] The message broker provides synchronized replication of changeddata so every known intercept software-enabled appliance or firewall hascurrent up-to-date policy data.

[0078] Key master software is device driver software only. It modifiesthe methodology controlling the creation and interpretation of uniqueSYN sequence numbers and acknowledgement (ACK) numbers. Using both thedigital key and fixed formulas, it generates a unique 32-bit sequencenumber and ACK number. Held within the sequence number are identifiersfor the active session and user ID. Held within the acknowledgementnumber are identifiers for the hardware and transformation keys.Although intercept software creates unique numbers they adhere to allInternet Engineering Task Force (IETF) Request for Comments (RFC)standards regarding protocol use of those numbers. As such, nomodifications are needed to normal infrastructure operations and packetdelivery.

[0079] In order to “turn-up” a new intercept system-enabled user, theuser needs to be added to the intercept system data store and have aunique key master (SID) created. The key master software utilizes theoriginal media access control hardware (MAC) address embedded as part ofthe SID and determines if the requesting workstation's present MACaddress is the same as the registered address. The SID is created bytaking the MAC address of the user's workstation plus the actual timestamp of the addition (measured in milliseconds).

[0080] This comparison prevents unknown devices from being connected attrusted locations such as a wiring closest. Additionally, it preventsillicit copies of the key master SID from being installed on unwantedsystems. If the MAC address comparison fails, key master softwareinforms the administrator and disallows connectivity.

[0081] When the user's workstation is enabled, he can use an applicationresource. When the user generates a request for connection, the keymaster software creates a unique SYN/ISN containing a 24-bit CRC of theUID that has been transformed plus a randomly selected GKI. The UID is afully qualified user name FQUN plus the domain name. This is computed bytaking the user ID name (e.g., dshay) and the authenticated domain nameand computing a 24-bit numerical value. The CRC is computed by takingthe UID and computing a normal cyclic redundancy check (CRC).

[0082] These numbers are then combined and computed using atransformation algorithm to create the unique SYN/ISN. Additionally, keymaster software computes a unique SID by taking the MAC address of theactive network interface card and the stored time stamp and creating a24-bit CRC numerical value. A randomly selected SKI is then combined tothis 24-bit number and the resulting 32-bit number is transformed tocreate the ACK number. Because the uniquely generated sequence numberand ACK numbers are 32 bits in length, they don't alter any requirementsspecified by the RFCs governing the TCP/IP protocol.

[0083] The complete SYN packet is then normally routed through thenetwork, heading towards its destination. Before it reaches itsdestination address; however, the packet is picked up by the gate keepersoftware. It begins by evaluating the ACK number. If the ACK numbercontains a zero value the request is recognized as an untrusted requestand is processed by the exception policy. The exception policy isapplied to verify a pre-existing policy for untrusted requestingsources. If the exception request is granted gate keeper assigns aunique identifiable ACK number that is understood by enabled receivingdevices; if no exception policy exists the request is dropped. If therequest is not identified as an exception (a non-zero ACK number), it isprocessed as an enabled request. As a normal enabled SYN packet, gatekeeper reforms the received ACK number yielding the SID and SKI. The SKIis then used to reform the ISN yielding a transformed UID and the GKI.The GKI is then used to reform the UID yielding a real UID. Continuingthe process, gate keeper then verifies the UID and selects the level ofpolicy to apply. If no other policy is defined for the UID, the packetis released. However, if additional levels of policy are defined, gatekeeper verifies each policy component. These policy components caninclude authorization of the hardware device by verifying the SID,application authorization by verifying the destination port identifieror any combination including all components.

[0084] From the combination of this information, the following is known:

[0085] intercept system-enabled request packet coming from a knowndevice;

[0086] the identification of the user that is making the request forconnection; and

[0087] where the user wants to go (destination) and what the user wantsto do (resources).

[0088] A set of permissions (i.e., policy) can now be evaluated for eachindividual user. If user “dshay” is authenticated to his normal domain,the intercept system will be able to recognize the user within the datastore and allow him to work within his restrictions. If the user (dshay)needs to use someone else's workstation, he will still need to find anintercept system-enabled node. In addition, the user will still have toauthenticate to his normal domain and be recognized by either thePrimary Data Controller (PDC) or the intercept system. As discussedabove, the PDC authenticates user names and passwords when members loginto the network. Members only have to log into one domain to access allresources in the network.

[0089]FIG. 4 illustrates the processing logic implemented in the keymaster software to control requests from end users for networkconnection services. Processing starts in logic block 400 with the userperforming a TCP/IP Open call requesting a connection to a networkservice. From an operating system perspective, end user workstationsrequesting a service ask the TCP services program to open a newconnection request which starts the functions needed to build a requestpacket (SYN) and to prepare the packet for transmission.

[0090] The TCP protocol requires the establishment of a controlledconnection between two devices before data can be exchanged. Thisconnection process requires the requesting device to send an InitialSequence Number (ISN) so that the connection can have a starting pointshared by both devices. As noted previously, the ISN is a 32-bit integerthat is randomly generated by the stack. The key master software takescontrol of the method by which this number is generated and creates anISN that holds a previously computed UID. The UID is then used toidentify the individual user making the request before the requestpacket is received at its destination. By using the FQUN computedearlier, a 24-bit CRC value is computed and stored in a session orientedtemporary variable.

[0091] Before the connection request begins, the key master softwareobtains the identification of the requesting machine (SID) and the useraccount identification (UD). By grabbing the Media Access Control (MAC)address of the network interface card (NIC) along with the original timestamp previously stored, a 24-bit transformed SID is created. Thisprocessing step is indicated by logic block 404. Located in the keymaster software, this function call is executed before the Open call,therefore it controls the go/no go state. By intercepting the connectionrequest, authorization decisions can be made before an intruder hasconnected to the network.

[0092] In decision block 406, a determination is made as to whether themachine (i.e., workstation) requesting connection is the same machineused during turn-up. By comparing the computed SID, the key mastersoftware can determine if the machine is the same machine used duringturn-up. If the key master software has been copied to another machine,or the access request is bound to a known network interface card (NIC),the session values will not match the stored values and the request willbe terminated. If the authentication check fails in decision block 406,the key master software will inform the security administrator of thefailed attempt to connect as indicated in logic block 408. This messageis reported and stored in the event database within the portal RDBMS.This information is used to identify and track unauthorized events.

[0093] The key master software includes two arrays of transformationkeys. First a GKI used to transform the UID and second the SKI used totransform outgoing packets. Each array has index pointers that areassociated with a key's value. After the UID has been computed, a GKIindex and an SKI are selected for the transformation steps. Thisprocessing step is indicated in logic block 410. The previously computedUID is transformed by the GKI as indicated in logic block 412.

[0094] As indicated in logic block 414, the GKI is then added to theresulting transformed UID. The previously selected SKI is then used totransform the resulting transformed UID plus GKI as indicated in logicblock 416. The resulting number is then used as the ISN and is stored inthe socket buffer and is ready for transmission (logic block 418). Thepreviously selected SKI is appended to the previously computed SID asindicated in logic block 420. The resulting number is then transformedas indicated in logic block 422. The transformed number is the IACK andis placed in the socket buffer as indicated in logic block 424. Theresulting SYN packet is now ready for transmission and is delivered bythe protocol transport system, as indicated by logic block 426.

[0095] The processing logic associated with the authentication processperformed by the gate keeper software is illustrated in FIG. 5. As shownin FIG. 1, the gate keeper 70 is an in-line active device. It performsservices similar to a typical firewall. It receives all packets thatflow bi-directionally on network circuits, investigates each packet,selects only specific packets for further processing, and releases allother packets. The processing logic for the gate keeper software can bedelineated into a number of processing blocks that are shown in FIG. 5.These process blocks include promiscuous packet capture; protocolidentification and packet identification; parsing and fetching;transformation/reformation; authorization verification; connectionaction; and notification. When executing in promiscuous mode, everypacket transmitted on to a protected circuit is captured and placed inthe input buffer. Protocol identification is performed by evaluating theIP header data in the packet. Once the protocol type code is identifiedas TCP, the packet header is again evaluated for an active SYN flag. Ifthe packet is a SYN packet, it is then further processed. If it is notan SYN packet, the packet is immediately released and sent on to itsdestination.

[0096] Processing commences in logic block 500 with the step ofreceiving a packet flow from a node. In step 502, the received packet isparsed. In decision block 504, a test is made to determine if the packetis a TCP packet. If it is, then in decision block 506, a test is made todetermine if the packet is an SYN packet. If it is not a SYN packet, thepacket is released as indicated in step 508. Once the packet has beendeclared a TCP packet with the SYN flag set, the ACK field is verified.In decision block 512, if the ACK field has a value greater than zero,then the ACK value and extracted SID/SKI are reformed as indicated inlogic block 516. If the ACK field has a value of zero, an exceptionroutine is then performed as indicated in logic block 514. Furtherdetails associated with the performance exception routine are depictedin FIG. 6. Following the reform process in logic block 516, the ISN isreformed. The reformed ISN reveals the transformed UID and the GKI asindicated in logic block 518. The GKI is then extracted as indicated inlogic block 520. Using the GKI, the transformed UID is reformed toreveal the user identification (UID) as indicated by logic block 522.The resulting UID is verified in logic block 524. If this is found to bea bad index number, the connection request is dropped. The resulting UIDis then searched for in the data store containing all known userprofiles. A test is made in decision block 526 to determine if the UIDhas been found. If the UID has been found, then it is passed on to thenext processing block, logic block 532 for further authentication. Ifthe resulting UID is not found (decision block 526), the connectionrequest is dropped (logic block 528) and a message is sent to theadministrator as indicated in block 530.

[0097] After the UID has been found (yes path out of decision block526), the UID process policy is inspected in logic block 532. Thisinspection informs the gate keeper software of the level of policy ineffect for this user. The process flags the five levels of policy toapply to each user. These policies provide for the inspection ofhardware (H), requested application (A), requested destination (D), andno policy at all (N). In decision block 534, a test is made to determineif there is a hardware or a requested application policy defined for theuser. If a hardware policy is defined, the SID is then verified asindicated in logic block 536. The SID identifies the source node makingthe request. A test is performed in decision block 538 to determine ifthe SID has been found. If the SID has not been found, then the requestis dropped (logic block 540) and a message is sent to the administratoras indicated in block 542. If the test in decision block 538 passes, thepacket is released to the destination, as indicated in logic block 546.In decision block 534, if an application policy is defined, thedestination port is verified (logic block 548). In decision block 550, atest is made to determine if the user is authorized to access therequested application. If the user is so authorized, the packet isreleased to the destination as indicated in logic block 560. Otherwise,the request is dropped (logic block 528) and a message is sent to theadministrator as indicated in logic block 530. If neither a hardwarepolicy nor a requested application policy is defined for the user, atest is then made in decision block 544 to determine if there is eithera requested destination policy or no policy at all defined for the user.If a requested destination policy is defined, a destination port isverified in logic block 552. If a destination port is accessible to theuser, then the packet is released to the destination as indicated inlogic block 560. If in decision block 554, the destination port is notavailable to the user, the request is dropped (logic block 556) and amessage is sent to the administrator, as indicated in block 558.

[0098]FIG. 6 illustrates the processing logic associated with the“performing exception” process. When the value held in the ACK field iszero, the gatekeeper software knows that the packet has originated froman untrusted source. The exception routine is executed because of therequirement to provide selected untrusted source access. The originationsource address is extracted from the IP layer in the verified sourceaddress logic block 600. The extracted source address is then verifiedfrom the exception table as indicated in decision block 602. If thistest fails, the connection request is dropped (logic block 604) and amessage is sent to the administrator in logic block 606. If theextracted source address is verified as a non-address in decision block602, the requested destination is then verified by extracting thedestination address in the IP layer. This is indicated in logic block608. The extracted destination address is then verified from theexception table in decision block 610. If the test fails, the request isdropped in logic block 604. If the extracted destination address isverified in decision block 610, then the packet is further tested byextracting the destination port number from the TCP layer to verify theapplication request in logic block 612. The destination port number isthen verified in the exception table as indicated in decision block 614.If the test fails, the request is dropped in logic block 604. If thetest passes in decision block 614, the request is then ready fortransformation. This transformation occurs in logic block 616 with thegeneration of a unique initial ACK number (IACK). This unique numberwill be authenticated by the key master software at the destination nodeas a recognized gate keeper-induced number. An SKI is selected next, asindicated in logic block 618. The selected SKI is then added to the IACKin logic block 620. The resulting number is then transformed in logicblock 622 and stored as the ACK in logic block 624. The SYN packet isfinally reassembled and the CHECKSUM is recalculated in logic block 626.The SYN packet is then released as indicated in logic block 628.

[0099]FIG. 7 illustrates the processing logic associated with call setup and response from a destination node, after receiving the packet fromgate keeper appliance 70. Processing starts in decision block 700 with atest to determine if an incoming packet is an SYN packet. The incomingpacket is inspected and tested for the SYN flag being set. If the SYNflag is set in the packet, set up processing is required. If the SYNflag is not set, the packet is not an SYN packet and the packet isdeemed as being associated with an established connection and isprocessed differently (see FIG. 8). If the SYN flag is set, then a testis performed in decision block 702 to determine if the ACK field isequal to zero. This test protects against untrusted nodes establishing aconnection. If the ACK field is zero, the packet is dropped in logicblock 704 and a message sent to the administrator in block 706. If theACK field is non-zero, further connection set up processing isperformed. The ACK is reformed utilizing the static routine in logicblock 708. The SKI is extracted from the transformed ACK number asindicated in logic block 710. The extracted SKI is then stored in abuffer variable (logic block 712) and is used throughout theconversation. Next, as indicated in logic block 714, the ISN is reformedusing the SKI to reveal the real sequence number. The resulting realsequence number is stored in the buffer as indicated in logic block 716.The ACK number is set to a zero value in logic block 718 with the zerovalue stored in the buffer in logic block 720. The resulting storednumbers (SEQ+ACK) are processed using normal stack processing, asindicated in logic block 722. Before the tcp_send ( ) function isexecuted, the sequence and ACK numbers are transformed using the storedSKI as indicated in logic block 724. The response packet is thentransmitted as indicated in logic block 726.

[0100]FIG. 8 illustrates the non-SYN packet processing flow that isexecuted after a connection has been established. Using the SKI storedduring connection set up, the sequence number is reformed to reveal thetrue sequence number as indicated in logic block 800. The resultingsequence number is then stored in the receive buffer as indicated inlogic block 802. Using the previously stored SKI, the ACK number isreformed to reveal the real ACK number in logic block 804. The resultingACK number is then stored in the receive buffer in logic block 806. Thepacket and its data then go through normal stack processing as indicatedin logic block 808. As the packet is processed by the stack and readiedfor transmission, the sequence number is once again transformed usingthe stored SKI in logic block 810. The normally produced ACK number isalso transformed using the stored SKI in logic block 812. The packet isthen placed in the transmit buffer by the stack and transmitted to itsdestination in logic block 814.

[0101] The present invention can be realized in hardware, software, or acombination of hardware and software. Any kind of computer system orother apparatus adapted for carrying out the methods described herein issuited. A typical combination of hardware and software could be ageneral purpose computer system with a computer program that, when beingloaded and executed, controls the computer system such that it carriesout the methods described herein. The techniques of the presentinvention can also be embedded in a computer program product, whichcomprises part or all of the features enabling the implementation of themethods described herein, and which, when loaded in a computer system,is able to carry out these methods.

[0102] Computer program in the present context mean any expression, inany language, code or notation, of a set of instructions intended tocause a system having an information processing capability to perform aparticular function either directly or after either or both of thefollowing occur: a) conversion to another language, code or notation; b)reproduction in a different material form. Computer program alsoencompasses hard-wired instructions embedded in an electronic deviceincluding semiconductor chips or cards, network appliances, routers,switches, servers, firewalls and client devices such as networkcomputers, workstations, desktop computers, laptop computers andhandheld devices. Specifically, a number of functions performed at theprotocol or packet level can be embedded in Application SpecificIntegrated Circuits (ASICs). Such functions can include the parsing orrouting of packets. The invention can also be embedded in single boardcomputers (SBCs) with a Linux operating system and silicon-based datastorage. Multiple boards can be installed in slots in a chassis as“blades” (similar to router blades in a router chassis) thus providingmultiple gate keeper appliances.

[0103] The corresponding structures, materials, acts, and equivalents ofany mean plus function elements in any claims are intended to includeany structure, material or acts for performing the function incombination with the other claimed elements as specifically claimed.

[0104] While the invention has been particularly shown and describedwith reference to a preferred embodiment thereof, it will be understoodby those skilled in the art that various other changes in form anddetail may be made without departing from the spirit and scope of theinvention.

What is claimed is:
 1. (new) A method comprising: transforming a useridentifier and a source identifier for a header of a packet.
 2. (new) Amethod as claimed in claim 1 wherein the transformed user identifier isincluded in an initial sequence number field of the packet.
 3. (new) Amethod as claimed in claim 1 wherein the transformed source identifiercomprises a non-zero value included in an acknowledgement field of thepacket.
 4. (new) A method as claimed in claim 1 wherein the useridentifier indicates a user associated with a source node that initiatescommunication over a network with a destination node by transmitting thepacket from the source node to the destination node.
 5. (new) A methodas claimed in claim 4 wherein the packet indicates a source node thatinitiates communication over a network with a destination node bytransmitting the packet from the source node to the destination node. 6.(new) A method as claimed in claim 1 wherein the packet indicates asource node that initiates communication over a network with adestination node by transmitting the packet from the source node to thedestination node.
 7. (new) A method as claimed in claim 1 wherein thepacket has a transfer control protocol/Internet protocol (TCP/IP)format.
 8. (new) A method as claimed in claim 1 wherein at least theuser identifier is transformed using a general key.
 9. (new) A method asclaimed in claim 8 wherein the user identifier is transformed using thegeneral key that is retrieved from a key table using arandomly-generated general key index.
 10. (new) A method as claimed inclaim 8 further comprising: appending the general key index to thetransformed user identifier.
 11. (new) A method as claimed in claim 1wherein at least the source identifier is transformed using a sessionkey.
 12. (new) A method as claimed in claim 1 wherein the transformingof the source identifier uses a session key retrieved using arandomly-generated session key index from a session key table stored ina source node at which the transforming is performed.
 13. (new) A methodas claimed in claim 12 further comprising: appending the session keyindex to the transformed source identifier.
 14. (new) A method asclaimed in claim 12 wherein the transformed source identifier andappended session key index are further transformed using a byte shuffle.15. (new) A method as claimed in claim 12 wherein the transformingfurther comprises inserting the transformed source identifier into anacknowledgement field of a header of the packet.
 16. (new) A method asclaimed in claim 1 further comprising: transmitting a packet includingthe transformed user identifier and source identifier from the sourcenode at which the transforming is performed, to a destination node. 17.(new) A method as claimed in claim 16 the method further comprising:receiving an acknowledgement packet from the destination node inresponse to the transmitted packet; and using the session key to reforminitial sequence number data and acknowledgement data from theacknowledgement packet.
 18. (new) A method as claimed in claim 1 whereinthe packet is a synchronization (SYN) packet used to initiatecommunication between source and destination nodes in transfer controlprotocol/Internet protocol (TCP/IP).
 19. (new) A method comprising:retrieving a first key from a table using a first key index;transforming a user identifier using the first key to form a transformeduser identifier; appending the first key index to the transformed useridentifier; and inserting the transformed user identifier with appendedfirst key index in a first field of a packet header.
 20. (new) A methodas claimed in claim 19 wherein the field is an initial sequence numberfield of the packet header.
 21. (new) A method as claimed in claim 19further comprising: retrieving a second key from a table using a secondkey index; transforming a source identifier using the second key to forma second transformed identifier; appending the second key index to thesecond transformed identifier; and inserting the transformed useridentifier with appended second key index in a second field of thepacket header.
 22. (new) A method as claimed in claim 21 wherein thefield is an acknowledgement field of the packet header.
 23. (new) Amethod comprising: retrieving a key from a table using a key index;transforming a source identifier using the key to form a transformedsource identifier; appending the key index to the transformed sourceidentifier; and inserting the transformed source identifier withappended key index in a field of the packet header.
 24. (new) A methodas claimed in claim 23 wherein the field is an acknowledgement field ofthe packet header.
 25. (new) A method comprising: providing at least onenode with software for transforming a user identifier and sourceidentifier to form a transformed header in a packet.
 26. (new) A methodas claimed in claim 25 wherein the packet is a synchronization (SYN)packet.
 27. (new) A method as claimed in claim 25 wherein thetransforming is performed using different keys for the user identifierand source identifier.
 28. (new) A method as claimed in claim 25 furthercomprising: distributing first and second key tables having first andsecond sets of keys to the node for use in transforming the useridentifier and source identifier, respectively.
 29. (new) A method asclaimed in claim 25 wherein the software is further for reforming a useridentifier and source identifier of a request for a network resourcehosted by the one node, that is received from at least one other node,to determine whether access to the network resource hosted by the onenode is permissible.
 30. (new) A method comprising: reforming a useridentifier and a source identifier of a header of a packet.
 31. (new) Amethod as claimed in claim 30 wherein the reforming comprises:retrieving a first key index from the header of the packet; retrieving afirst key corresponding to the first key index; reforming the sourceidentifier and a second key index from the header using the first keyindex; retrieving a second key using the second key index; and reformingthe user identifier using the second key index.
 32. (new) A method asclaimed in claim 30 wherein the user identifier and source identifierare used to retrieve policy data indicating whether a corresponding userand source are authorized to access a network resource identified by thepacket header.
 33. (new) A method as claimed in claim 32 wherein thepolicy data is defined by at least one of the user indicated by the useridentifier, the source indicated by the source identifier, a destinationport indicated by the packet, and an application sought to be accessedby a request indicated by the packet.
 34. (new) A method as claimed inclaim 32 wherein the network resource includes a destination node. 35.(new) A method as claimed in claim 32 wherein the network resourceincludes an application.
 36. (new) A method as claimed in claim 32wherein the network resource includes data.
 37. (new) A method asclaimed in claim 30 further comprising: determining whether the user andsource identified by the user identifier and source identifier,respectively, are authorized to communicate with a destination node;permitting the packet to pass to the destination node if thecommunication requested by the packet is permitted; and prohibiting thepacket from passing to the destination node if the communicationrequested by the packet is not permitted.
 38. (new) A method as claimedin claim 30 wherein the packet is a synchronization (SYN) packet. 39.(new) A method as claimed in claim 30 further comprising: switching thepacket to a network node determined by the user identifier.
 40. (new) Amethod as claimed in claim 39 wherein the switching is further performedbased on the source identifier.
 41. (new) A method as claimed in claim30 further comprising: switching the packet to a network node determinedby the source identifier.
 42. (new) A method as claimed in claim 30wherein the switching is performed by using a table to determine thedestination node from the destination indicated by the packet.
 43. (new)A method comprising: providing at least one node with software forreforming a user identifier and source identifier from a packet receivedfrom at least one other node to determine whether the packet ispermitted to be passed to a destination indicated by a header of thepacket.
 44. (new) A method as claimed in claim 43 wherein the packet isreceived from a public communications network.
 45. (new) A method asclaimed in claim 43 wherein the public communications network is theInternet.
 46. (new) A method as claimed in claim 43 wherein the softwarecan further be used to transform the user identifier and sourceidentifier to form a transformed header in the packet.
 47. (new) Amethod as claimed in claim 46 wherein the software can be used todetermine whether policy data exists based on at least one of the useridentifier, the source identifier, a network resource requested by thepacket, and a destination of the packet.
 48. (new) A method as claimedin claim 46 wherein the software can further be used to determinewhether the user identifier and source identifier are associated with atrusted entity.
 49. (new) A method as claimed in claim 46 wherein thesoftware can further be used to determine, if the packet originated froma trusted entity, whether an access policy exists for the trustedentity.
 50. (new) A method as claimed in claim 49 wherein, if the accesspolicy exists, the software can be used to apply the access policy todetermine whether the trusted entity is permitted access to a networkresource and destination.
 51. (new) A method as claimed in claim 50wherein, if the access policy does not exist, the software permits thetrusted entity access to the requested network resource and entity. 52.(new) A method as claimed in claim 51 wherein, if the softwaredetermines that the packet originates from an untrusted entity, thesoftware determines whether an exception policy exists under which theuntrusted entity may be permitted access to the requested networkresource and destination.
 53. (new) A method as claimed in claim 52wherein, if the software determines that no exception policy exists, thesoftware terminates the request.
 54. (new) A method as claimed in claim53 wherein, if the software terminates the request, the software reportsthe attempt of the untrusted entity to access the network resource anddestination to a network administrator.
 55. (new) A method as claimed inclaim 54 wherein, if the software terminates the request, the softwarestores a record of the attempt of the untrusted entity to access thenetwork resource and destination in an unauthorized access database. 56.(new) A method as claimed in claim 52 wherein, if the softwaredetermines that an exception policy exists for the untrusted entity, thesoftware further determines whether the exception policy permits theuntrusted entity to access the network resource and destination. 57.(new) A method as claimed in claim 56 wherein, if the softwaredetermines that the untrusted entity is not permitted to access thenetwork resource and destination indicated by the request, the softwareterminates the request.
 58. (new) A method as claimed in claim 57wherein the software further reports the request attempting to accessthe network resource and destination to a network administrator. 59.(new) A method as claimed in claim 57 wherein the software furtherstores a record of the request attempting to access the network resourceand destination in an unauthorized access database.
 60. (new) A methodas claimed in claim 59 wherein, if the software determines that the useris authorized to access the requested network resource and destination,the software transforms the user identifier and source identifier andinserts same in the header of the packet, inserts a non-zero value intothe acknowledgement field of the packet, stores the non-zero value in amemory location accessible to the destination node indicated by thepacket, and releases the packet with transformed packet header to thedestination node.
 61. (new) A method as claimed in claim 43 wherein thepacket is a synchronization (SYN) packet.
 62. (new) A method as claimedin claim 43 wherein the reforming is performed using different keys forthe user identifier and source identifier.
 63. (new) A method as claimedin claim 43 further comprising: distributing first and second key tableshaving first and second sets of keys to the node for use in transformingthe user identifier and source identifier, respectively.
 64. (new) Amethod as claimed in claim 43 wherein the software can be used to switchthe packet to a destination port indicated by the packet based on atleast one of the user identifier and source identifier.
 65. (new) Amethod as claimed in claim 43 wherein the software can be used to switchthe packet to a destination node based on the user identifier and sourceidentifier.
 66. (new) A method comprising: determining whether asynchronization packet has a non-zero value in an acknowledgement fieldof a header of the packet.
 67. (new) A method as claimed in claim 66further comprising: if the packet has the non-zero value in theacknowledgement field, reforming at least one of a user identifier andsource identifier contained in the packet header.
 68. (new) A method asclaimed in claim 66 further comprising: if the packet does not have thezero value in the acknowledgement field, reforming a user identifier andsource identifier from the packet header.
 69. (new) A method as claimedin claim 68 wherein the reforming is performed using different keys forthe user identifier and the source identifier.
 70. (new) A method asclaimed in claim 68 wherein at least one of the user identifier andsource identifier are used to determine whether access policy dataexists to define rights of at least one of the user and source to accessat least one of a network resource and destination port identified bythe packet.
 71. (new) A method as claimed in claim 70 wherein thenetwork resource comprises an application.
 72. (new) A method as claimedin claim 70 wherein the network resource comprises data.
 73. (new) Amethod as claimed in claim 70 wherein the destination port is associatedwith a destination node.
 74. (new) A method as claimed in claim 66further comprising: if the determining establishes that theacknowledgement field has a zero value, terminating a request fornetwork service requested by the packet unless an exception policyauthorizes the packet to proceed to a destination node indicated by thepacket.
 75. (new) A method as claimed in claim 74 wherein the exceptionpolicy is defined based on at least one of a user identifier included inthe packet, a source identifier included in the packet, a networkresource requested by the packet, and a destination port indicated bythe packet.
 76. (new) A method as claimed in claim 66 furthercomprising: terminating communication associated with the packet if thepolicy data determines that transfer of the packet to a destination portindicated by the packet header is not authorized.
 77. (new) A method asclaimed in claim 76 further comprising: permitting the packet to pass tothe destination port identified by the packet if the policy dataindicates that communication with the packet header is authorized. 78.(new) A method as claimed in claim 76 further comprising: permitting thepacket to pass to the destination port identified by the packet if thepolicy data indicates that communication with the packet header isauthorized.
 79. (new) A method as claimed in claim 76 furthercomprising: determining whether the packet has a transport controlprotocol/Internet protocol (TCP/IP) format, the determining whether thesynchronization packet has the non-zero value performed only if thepacket has the TCP/IP format.
 80. (new) A method comprising: inserting anon-zero value into an acknowledgement field of a header of asynchronization (SYN) packet.
 81. (new) A method as claimed in claim 80wherein the non-zero value comprises at least one of a transformed useridentifier and a transformed source identifier.
 82. (new) A method asclaimed in claim 80 wherein the non-zero value comprises a transformeduser identifier and a transformed source identifier.
 83. (new) A methodcomprising: determining whether a packet originated from a trustedentity, the determining performed by establishing whether anacknowledgement field of a header of the packet has a non-zero value.84. (new) A method as claimed in claim 83 wherein the identity of thetrusted entity is defined by a user identifier and source identifierincluded in the packet.
 85. (new) A method as claimed in claim 83further comprising: if the determining establishes that the packetoriginated from a trusted entity, determining access rights of thetrusted entity to access at least one of a network resource anddestination node indicated by the packet.
 86. (new) A method as claimedin claim 85 wherein the access rights are defined based on at least oneof a user identifier, a source identifier, a network resource, and adestination port indicated by the packet.
 87. (new) A method as claimedin claim 85 wherein the packet is a synchronization (SYN) packet. 88.(new) A method as claimed in claim 83 further comprising: if thedetermining establishes that the packet originated from an untrustedentity, determining access rights of the untrusted entity under anexception policy applied with respect to a request for a networkresource indicated by the packet.
 89. (new) A method as claimed in claim85 further comprising: determining whether the packet is asynchronization packet, said determining whether the packet originatedfrom the trusted entity performed only if the packet is determined to bea synchronization packet.
 90. (new) A method comprising: determiningwhether a request to access a network resource originates from a trustedentity; if the request to access the network resource originates from atrusted entity, permitting the request to access the network resource ifan access policy permits the trusted entity to access to the networkresource or if no policy exists relative to the trusted entity; and ifthe request to access the network resource does not originate from atrusted entity, prohibiting the request to access the network resourceunless an exception policy permits the untrusted entity to access thenetwork resource.
 91. (new) A method as claimed in claim 90 furthercomprising: if the request to access the network resource is prohibited,storing a record of the request to access the network resource in anunauthorized request database.
 92. (new) A method as claimed in claim 91wherein the record comprises an identity of the entity originating therequest.
 93. (new) A method as claimed in claim 92 wherein determinationof whether the entity is trusted is made on the basis of a useridentifier included in the request.
 94. (new) A method as claimed inclaim 93 wherein the determination of whether the entity is trusted isfurther made on the basis of a source identifier included in therequest.
 95. (new) A method as claimed in claim 94 wherein thedetermination of whether the entity is trusted is made on the basis of asource identifier included in the request.
 96. (new) A method as claimedin claim 90 wherein the network resource comprises an application. 97.(new) A method as claimed in claim 90 wherein the network resourcecomprises data.
 98. (new) A method as claimed in claim 90 wherein thedetermination of whether the request originates from a trusted entity ismade based on whether an acknowledgement field in a packet including therequest has a non-zero value.
 99. (new) A method as claimed in claim 90wherein the request is contained in a synchronization (SYN) packet. 100.(new) A method as claimed in claim 90 wherein the access policy isdefined based on at least one of a user identifier included in thepacket, a source identifier included in the packet, a network resourcerequested by the packet, and a destination port indicated by the packet.101. (new) A method as claimed in claim 90 wherein the exception policyis defined based on at least one of a user identifier included in thepacket, a source identifier included in the packet, a network resourcerequested by the packet, and a destination port indicated by the packet.102. (new) A method comprising: storing a table of general keys inassociation with corresponding general key indexes, and a table ofsession keys in association with corresponding session key indexes, foruse in transforming user and source identifiers.
 103. (new) A method asclaimed in claim 102 further comprising: randomly selecting one of thegeneral keys for use in transforming a user identifier for inclusion ina packet header.
 104. (new) A method as claimed in claim 102 furthercomprising: randomly selecting one of the session keys for use intransforming a source identifier for inclusion in a packet header. 105.(new) A method comprising: storing a table of general keys inassociation with corresponding general key indexes, and a table ofsession keys in association with corresponding session key indexes, foruse in reforming user and source identifiers.
 106. (new) A method asclaimed in claim 105 further comprising: extracting a session key indexfrom a packet; retrieving a session key with the session key index;extracting a source identifier and a general key index from the packetusing the session key; retrieving a general key using the general keyindex; extracting a user identifier from the packet using the generalkey.
 107. (new) A computer-readable medium storing a table of generalkeys in association with corresponding general key indexes, and a tableof session keys in association with corresponding session key indexes,for use in transforming user and source identifiers.
 108. (new) Acomputer-readable medium as claimed in claim 107 wherein the generalkeys are randomly selected for use in transforming a user identifier forinclusion in a packet header
 109. (new) A computer-readable medium asclaimed in claim 107 wherein the session keys are randomly selected foruse in transforming a source identifier for inclusion in a packetheader.
 110. (new) A computer-readable medium storing a table of generalkeys in association with corresponding general key indexes, and a tableof session keys in association with corresponding session key indexes,for use in reforming user and source identifiers.
 111. (new) Acomputer-readable medium as claimed in claim 110 wherein the tables ofgeneral keys and session keys are used to extract general and sessionkey indexes from a packet, using the general and session key indexes toretrieve general and session keys, respectively, and reforming user andsource identifiers from the packet using the general and session keys.112. (new) A method comprising: distributing first and second key tablesto at least one node for use in establishing an entity associated withthe node as a trusted entity.
 113. (new) A method as claimed in claim112 wherein the first and second key tables are for use in transforminga user identifier and source identifier included in a request for anetwork resource generated by the node for transmission to at least oneother node associated with another trusted entity.
 114. (new) A methodas claimed in claim 112 wherein the first key table comprises generalkeys used to transform the user identifier included in the request. 115.(new) A method as claimed in claim 114 wherein the second key tablecomprises session keys used to transform the source identifier includedin the request.
 116. (new) A method as claimed in claim 112 wherein thesecond key table comprises session keys used to transform the sourceidentifier included in the request.
 117. (new) A method comprising:executing software comparing a source identifier of a node with a sourceidentifier included in the software; if the source identifier of thenode matches the source identifier of the software, continuing toexecute the software; and if the source identifier of the node does notmatch the source identifier of the software, terminating execution ofthe software.
 118. (new) A method as claimed in claim 117 wherein thesource identifier is determined based on the media access control (MAC)address of the machine.
 119. (new) A method as claimed in claim 117wherein the source identifier is further determined based on atimestamp.
 120. (new) A method as claimed in claim 117 wherein thetimestamp is determined based on a time of registration of the node as atrusted node.
 121. (new) A method comprising: providing an identifieridentifying a node in software, the software executable by the node tocompare the source identifier of the software with the source identifierof the node, the software continuing to execute if the identifier of thesoftware matches the identifier of the node, and the softwareterminating execution if the identifier of the software does not matchthe identifier of the node.
 122. (new) A method as claimed in claim 121wherein the software can be used for secure communications between thenode and at least one other node.
 123. (new) A method as claimed inclaim 121 wherein the software can be used to authenticate the node toat least one other node.
 124. (new) A method as claimed in claim 121wherein the identifier is derived from the media access control (MAC)address of the node.
 125. (new) A method as claimed in claim 124 whereinthe identifier is further derived from a timestamp.
 126. (new) A methodas claimed in claim 125 wherein the timestamp is associated with a timeof registration of the node as corresponding to a trusted entity. 127.(new) A system for entities to communicate via a network, the systemcomprising: a first node executing software for transforming a useridentifier and source identifier included in a request to access anetwork resource, the first node transmitting the request on thenetwork. a second node connected to communicate with the first node viathe network, the second node receiving the request from the first nodeand reforming the user identifier and source identifier contained in therequest, the second node using the user identifier and the sourceidentifier to determine whether the request is to be passed orterminated; and a third node connected to communicate with the secondnode, the third node indicated as the destination of the request foraccess to the network resource and receiving and executing the requestif passed from the second node.
 128. (new) A system as claimed in claim127 wherein the first node includes the request in a synchronizationpacket.
 129. (new) A system as claimed in claim 128 wherein the firstnode includes the transformed user identifier in an initial sequencenumber field of a packet containing the request.
 130. (new) A system asclaimed in claim 129 wherein the first node includes the transformedsource identifier in an acknowledgement field of the packet containingthe request.
 131. (new) A system as claimed in claim 128 wherein thefirst node includes the transformed source identifier in anacknowledgement field of the packet containing the request.
 132. (new)system as claimed in claim 131 wherein the transformed source identifierhas a non-zero value, the second node using the fact that theacknowledgement field contains such non-zero value to determine that theuser identifier and source identifier are contained in the request. 133.(new) A system as claimed in claim 131 wherein the second node reformsthe user identifier and source identifier and compares same againststored data to determine whether the request is to be passed to thethird node.
 134. (new) A system as claimed in claim 133 wherein thestored data comprises an access policy defined by at least one of theuser identifier, source identifier, a requested network resourceindicated by the request, and the identity of the third node to whichthe request is directed.
 135. (new) A system as claimed in claim 127wherein the first, second, and third nodes comprise respectivecomputers.
 136. (new) An apparatus connected to communicate via anetwork, the apparatus comprising: a node connected to the network, fortransforming a user identifier and source identifier for inclusion in arequest for transmission on the network.
 137. (new) An apparatus asclaimed in claim 136 wherein the node includes the request in asynchronization packet.
 138. (new) An apparatus as claimed in claim 137wherein the node includes the transformed user identifier in an initialsequence number field of a packet containing the request.
 139. (new) Anapparatus as claimed in claim 138 wherein the node includes thetransformed source identifier in an acknowledgement field of the packetcontaining the request.
 140. (new) An apparatus as claimed in claim 136wherein the node includes the transformed source identifier in anacknowledgement field of the packet containing the request.
 141. (new)An apparatus as claimed in claim 136 wherein the transformed sourceidentifier has a non-zero value.
 142. (new) An apparatus as claimed inclaim 136 wherein the node transforms the user identifier with a generalkey.
 143. (new) An apparatus as claimed in claim 142 wherein the nodetransforms the source identifier with a session key.
 144. (new) Anapparatus as claimed in claim 136 wherein the node transforms the sourceidentifier with a session key.
 145. (new) An apparatus as claimed inclaim 136 wherein the node comprises a computer.
 146. (new) An apparatusconnected to communicate via a network, the apparatus comprising: a nodefor receiving a request to access a network resource via the network,the node determining whether the request contains a transformed useridentifier and source identifier, and if the request contains thetransformed user identifier and source identifier, the node reforms theuser identifier and source identifier.
 147. (new) An apparatus asclaimed in claim 146 wherein the node uses the user identifier andsource identifier to determine whether the packet is to be released to adestination indicated by the request.
 148. (new) An apparatus as claimedin claim 147 wherein the node uses the user identifier and sourceidentifier to switch the packet to a destination corresponding to atleast the user identifier and source identifier and the destinationindicated by the packet.
 149. (new) An apparatus as claimed in claim 148wherein the node refers to a stored table of switching data to determinethe destination to which the request is to be switched.
 150. (new) Anapparatus as claimed in claim 147 wherein the request is contained in asynchronization packet.
 151. (new) An apparatus as claimed in claim 150wherein the node determines that the request has a transformed useridentifier and source identifier if the synchronization packet has anon-zero value in an acknowledgement field thereof due to inclusion ofat least one of the user identifier and source identifier in suchacknowledgement field.
 152. (new) An apparatus as claimed in claim 150wherein the node reforms the source identifier with a session keyobtained from a session key table stored at the node using a session keyindex contained in the synchronization packet.
 153. (new) An apparatusas claimed in claim 152 wherein the node reforms the user identifierusing a general key obtained from a general key table stored at the nodeusing a general key index contained in the synchronization packet. 154.(new) An apparatus as claimed in claim 146 wherein, if the requestcontains the transformed user identifier and source identifier, the nodereforms the user identifier and source identifier to determine whethercorresponding access policy data exists to define whether the request toaccess the network resource is to be permitted.
 155. (new) An apparatusas claimed in claim 146 wherein the access policy data is defined basedon at least one of the user identifier, the source identifier, thenetwork resource indicated by the request, and the destination portindicated by the packet.
 156. (new) An apparatus as claimed in claim 146wherein the node releases the request to a destination node indicated bythe request if no access policy data exists for the user identifier andsource identifier.
 157. (new) An apparatus as claimed in claim 146wherein, if the node determines that the request contains no useridentifier and source identifier, the node refers to stored exceptionpolicy data to determine whether the request is to be permitted to bereleased to a destination port indicated by the request.
 158. (new) Anapparatus as claimed in claim 157 wherein the exception policy data isdefined based on at least one of the user identifier, the sourceidentifier, the network resource indicated by the request, and thedestination port indicated by the packet.
 159. (new) An apparatus asclaimed in claim 158 wherein the exception policy data indicates thatthe packet is to be released, and the node generates and inserts anon-zero value in the acknowledgement field of the synchronizationpacket, stores the non-zero value in a location accessible to adestination node at the destination port indicated by the packet, andreleases the packet to the destination port for access by thedestination node.
 160. (new) An apparatus as claimed in claim 158wherein the node terminates the request if the exception policyindicates that the packet is not to be released to a destination portindicated by the packet.
 161. (new) An apparatus as claimed in claim 160wherein the node reports the request to access the network resource to anetwork administrator.
 162. (new) An apparatus as claimed in claim 160wherein the node stores a record of the request in an unauthorizedaccess database.
 163. (new) An apparatus as claimed in claim 146 whereinthe network resource comprises an application.
 164. (new) An apparatusas claimed in claim 146 wherein the network resource comprises data.165. (new) An apparatus as claimed in claim 146 wherein the nodecomprises a computer.
 166. (new) An apparatus receiving a packetrequesting a network service, the apparatus comprising: a node connectedto receive a packet, the node determining whether the packet is asynchronization packet, and if the packet is a synchronization packet,the node determining whether an acknowledgement field of the packetcontains a non-zero-value, if the packet has a non-zero value, thepacket continuing to process the packet to provide the requested networkservice, and if the synchronization packet has a zero value in theacknowledgement field of the packet, the node dropping the packet. 167.(new) An apparatus as claimed in claim 166 wherein, if thesynchronization packet contains the non-zero value, the node continuesto process the request by using an encryption key to reform the a sourceidentifier and session key index, retrieving a session key from a tablebased on the session key index, and using the session key to reform aninitial sequence number, the node zeroing the acknowledgement field, andstoring the initial sequence number data and zeroed acknowledgement foruse in communicating with a remote node from which the packetoriginated.
 168. (new) An apparatus as claimed in claim 167 wherein thenode retrieves and uses the session key indicated by the session keyindex to transmit a packet to the remote node to continue packetcommunications for the session with the remote node.